-
Notifications
You must be signed in to change notification settings - Fork 52
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Multi get, pluggable hashing and some code cleanup (#1) #145
Conversation
Hey @blackmad, thanks so much for all the work. I have only looked at the pluggable hash function so far. I don't think removing failover is a good idea for a couple of reasons.
The good thing is that I don't think it is hard to keep failover at all. For the default function, you can just leave the "use next server" failover. Personally, I would also recommend the same failover for |
Thanks for the review!
I originally had a version with hashring but noticed that the project had
zero external dependencies so thought you might want to keep it that way,
rewriting it to be pluggable ended up with cleaner code so I'm glad I did
it, but awesome can add back in hashring in the future.
re: failover, sounds like a simple change - I'll try to get in back in
today.
…On Mon, Mar 29, 2021 at 4:51 AM Sascha ***@***.***> wrote:
Hey @blackmad <https://github.com/blackmad>, thanks so much for all the
work.
I have only looked at the pluggable hash function so far.
I don't think removing failover is a good idea for a couple of reasons.
- Without failover, you will be dogpiling servers whenever there is an
issue... and in the cloud, there is always an issue eventually.
- For MemCachier caches, servers have a consistent view of the cache,
so failovers are highly desirable since you will get the same answer from
any server.
The good thing is that I don't think it is hard to keep failover at all.
For the default function, you can just leave the "use next server"
failover. Personally, I would also recommend the same failover for
hashring as it is common practice. Btw. feel free to add the hashring
function to choose a server to memjs in a future PR as well. I think
@alevy <https://github.com/alevy> has a TODO about adding one in the code
anyway. The good thing about having both in memjs is that you can reuse
the "use next server" failover.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#145 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AADMZMBP3J2QQUWYDXPW2WDTGBETNANCNFSM4Z3LJ37Q>
.
--
*David Blackman*
creative technologist & wandering
help me find my purpose <http://purpose.blackmad.com>
|
Add type file with `getMulti`
* version and versionAll * PR feedback
Is the pluggable Hash going to be rolled into the main branch anytime soon? I'd love to be able to use this but need to write our own Hash support at the moment (horrible old PHP |
@blackmad any update? Have you thought about the 3 options above? |
added callbacks to versionAll
Auto Reconnect when socket is closed
Add getMultiWithErrors
Previous behavior was to hang forever on unexpected close or unhandled error response.
…-many-conns Error out waiting clients on close, handle too many connections
…onnect Reset responseBuffer on error, close, and new connections
bump version to clear circleCI cache
Add versionAllWithErrors to return info on which hosts succeeded or failed
Unifies error handling/resetting state in error()
…meout Destroy() socket on timeout
This change implements multi-get, pluggable hashing and some (but not complete) code cleanup
pluggable hashing
code cleanup
I'd really like to move the eslint version forward so we can use const, let, =>, and array destructuring, but that seemed like it would be better suited to a separate PR